fix(approvals): roll a standing grant back when its save is refused - #2768

@Birfy — review request at tip 02964141327f003fc32b57f3b5db189e83f1281b (one request per tip; this head is unchanged since it was opened).

What it fixes. grantStanding() and removeStandingApproval() in core/src/host/approvals.js changed the in-memory standing-approval list first and awaited rt.save() afterwards, so a refused save left the grant in effect in memory while the disk kept the old state. The worst shape is fail-open: the owner is told the answer was not saved, and the next card of the same kind is then answered allowed-once from the grant that was never persisted. removeStandingApproval failed the other way round — the grant vanished from memory while the disk still held it.

The fix. const before = target.standingApprovals → replace → await rt.save(); on a throw, before === undefined ? delete target.standingApprovals : target.standingApprovals = before and rethrow. The loop that answers the other pending cards allowed-once stays on the success path, below the await, so a refusal cannot reach it; revision is not rolled back.

Red first at base f2ef4dfa, the PR's core/test/group-status.test.js only, source files at base: 30 tests / 27 pass / 3 fail — not ok 21 the refused grant stayed in the Bot's record, not ok 22 the refused grant stayed on the group, not ok 23 the grant the refused removal could not delete is gone. Same file after the change: 30/30.

Checks at this tip (02964141…): 18 runs = 15 success + 2 skipped + 1 failure. The one failure is enqueue-guard — no Verifier report names the tip 02964141327f — which is what this request is for; tests-ok, merge-gate, policy-sign, risk tier, package and every plugin job are green.

Independent passes (advisory, not the gate). FlyBot Test re-ran the red-first on a clean base (same 30/27/3) and wrote its own runtime probe: 38/38 on the tip vs 24/38 on the base, with the base failing on four shapes including "refused Bot-scope grant answers the next same-kind card allowed-once". FlyBot Security read the rollback paths (store.js throws only before the rename, so no half-written state) and the before reference (nothing mutates standingApprovals in place) and found no new authz surface; it recorded one follow-up about two overlapping writers on the same target, which is out of this diff and will be its own issue.

Tier T2 (core/src/host/**), so this needs the Verdict naming this tip before it can be enqueued.

Verdict: PASS at 0296414
Written-by: Reviewer

No actionable findings at this tip. I reviewed it independently of the PR narrative: the base source, the tip source, the new tests, the docs change, the fragment and the generated patch.

The defect is real on the base, in the exact shape the issue describes. At base f2ef4dfa, core/src/host/approvals.js:142-143 assigns target.standingApprovals = [...grants, grant] and only then awaits rt.save(); a throw from that await leaves the assignment in memory. :160-162 is the mirror: it deletes/replaces the grant and then saves, so a refused removal leaves the list saying "gone" while disk still holds it. standingGrant (:102-109) matches on kind, so the surviving grant answers the next ask before any card is created. The refusal is reachable: core/src/host/store.js:1022 refuses the write when the temp name state.json.<pid>.tmp is a link/hard link/directory, and the error text is the one the new tests match.

The fix rolls back only the in-memory list and rethrows. const before = target.standingApprovals snapshots the reference, the new list is assigned, and the catch puts before back (or deletes the key when there was none) before rethrowing. revision is not restored, and the loop that releases other covered cards stays below the await, so a refused answer cannot reach it. Cards stay pending because entry.answer(outcome) is after grantStanding. Nothing else in the two functions changed; removeStandingApproval's before/grants split keeps the same filter and the same return false early exit.

The new cases are red on the base for the intended reason. The tip test file dropped onto the base tree (only the source change reverted) runs 30 tests / 27 pass / 3 fail, exactly the three new cases: not ok 21 the refused grant stayed in the Bot’s record, not ok 22 the refused grant stayed on the group, not ok 23 the grant the refused removal could not delete is gone. The same file on the tip tree is 30/30, twice. So the assertions pin the rollback and the still-pending card, not merely "the request was refused".

The generated patch matches the source. Every hunk of the src/host/approvals.js section (5/5) and the test/group-status.test.js section (6/6) of patches/ds-bot/0001-core-fixes.patch re-applies in order onto the tip files, and node scripts/ds-bot-patches.mjs check reports 10 patches apply cleanly in order and core/ equals ds-bot/ + patches/ds-bot/. The fragment is a .fixed.md naming #2764 and the user-visible change; changelog.mjs check reports 17 well-formed fragments. docs/subsystems/core-host.md updates the standing-approvals paragraph in the same PR, so the owned-path doc rule is satisfied.

Tier note: the base risk-gate.mjs judges this diff T3 (path core/src/host/approvals.js; approvals.js is in the T3 path list, not T2 as the body's Risk tier: line says). T2 and T3 take the same path here — a PASS at the tip, green required checks, queue — so this changes nothing about the gate, but the body's tier line is inaccurate.

Behaviour note, not a finding: two always-* answers whose saves interleave can have the failed one restore a snapshot older than the other's grant while the store's queued write persists the later snapshot; every request starts with load()/refresh(), which adopts the changed file, so it is not a fail-open, and the same non-transactional read-modify-write shape predates this change (it needs a store-level transaction, not this PR).

Ran:

• cd core && DSH_HARNESS=/opt/flybot TZ=UTC node --import ./test/harness-resolve.mjs --test test/group-status.test.js on the tip tree 02964141 → pass, 30/30, twice
• the same command with the tip test/group-status.test.js copied onto the base tree f2ef4dfa (source unchanged) → fail 3/30: not ok 21 (refused Bot-scope grant still in the record), not ok 22 (room-scope grant still on the group), not ok 23 (refused removal still gone from memory)
• node script that applies every hunk of the patch's src/host/approvals.js and test/group-status.test.js sections to the tip files in order → pass, 5/5 and 6/6 hunks, consuming the files to their last line
• node scripts/ds-bot-patches.mjs check at the tip → ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/ (the pin hash line is skipped without git)
• node .github/scripts/changelog.mjs check at the tip → pass, 17 fragment(s) in changelog.d/ are well formed
• createGate(loadRules(base .github/agent/risk-rules.json)).judge(<PR 2768 files>) over the API's changed files → T3, path core/src/host/approvals.js

Not run:

• full npm test / npm run verify here — the tip's tests-ok is green at this same sha and aggregates the test, plugins, package and policy-sign jobs, so the full suite ran in CI
• node core/scripts/build-client.mjs --check — this diff does not touch src/client/ or client.js
• smoke / Desktop / real-model steward — not in scope for this host-side fix

This PASS names only the tip above; a new commit voids it. It is a conclusion, not merge authority: the enqueue guard and merge-gate re-read the live head.